home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: tank.news.pipex.net!pipex!warwick!bsmail!talisker!nathan
- From: nathan@pact.srf.ac.uk (Nathan Sidwell)
- Subject: protected access to grandparent class
- Message-ID: <Dnqstp.Jo9@uns.bris.ac.uk>
- Sender: usenet@uns.bris.ac.uk (Usenet news owner)
- Nntp-Posting-Host: talisker.pact.srf.ac.uk
- Organization: Inmos
- X-Newsreader: TIN [version 1.2 PL2]
- Date: Mon, 4 Mar 1996 12:17:49 GMT
-
- The following class heirarchy is giving me grief.
- -snip
- class A {
- protected:
- int member;
- void func(A){};
- };
-
- class B : protected A {
- protected:
- void func(B arg) {
- A::func(A(arg)); // ok
- };
- };
-
- class C : protected B {
- protected:
- void func(C arg) {
- A::func(A(arg)); // failed
- };
- };
- -snip
-
- As far as I can determined the line marked 'failed' is class C's equivalent
- of the line marked 'ok'. However, g++ 2.7.2 says,
-
- foo.cc: In method `void C::func(class C)':
- foo.cc:17: fields of `const A' are inaccessible in `C' due to private inheritance
- foo.cc:5: in passing argument 1 of `A::A(const A &)'
- foo.cc:17: in conversion to type `A'
-
- and cfront says,
-
- "foo.cc", line 17: error: cast: C* -> base A*; protected base class
- "foo.cc", line 17: error: object or pointer missing for A::func() of type void A::(A)
-
- however, SGI CC accepts the code.
-
- I can't see anything in 11.2 of the draft standard which indicates that the rule
- it describes cannot be applied recursively -- it doesn't describe any other
- method for determining the access to grandparent members.
-
- Is my understanding incomplete or are g++ and cfront confused?
-
- nathan
-
-
- --
- Nathan Sidwell Holder of the Xmris home page
- Chameleon Architecture Group at SGS-Thomson, formerly Inmos
- http://www.pact.srf.ac.uk/~nathan/ Tel 0117 9707182
- nathan@inmos.co.uk or nathan@bristol.st.com or nathan@pact.srf.ac.uk
-